The process of booting a computing device prepares the computing device to perform useful tasks under control of an operating system. The initial application of power to the electronic circuitry of a computing device generally only renders the computing device capable of performing rudimentary tasks, such as fetching instructions embedded into hardware components of the computing device. Thus, the boot process executes those instructions, and initiates processes that enable a computing device to perform more complex tasks. However, because the boot process performs operations prior to the execution of the operating system and any other software whose execution utilizes the operating system, malicious code executed during the boot process can remain undetected but can affect the ongoing execution properties of the system.
To provide protection against malicious code, the notion of a “trusted computer” was developed whereby the state of the computing device could be ascertained. To that end, a “Trusted Platform Module” (TPM) chip was added to the computing device, which could maintain values in a secure manner and, thereby, be used to ascertain if the computer had booted properly. In particular, the TPM chip comprises registers known as “Platform Configuration Registers” (PCRs) that store values that uniquely identify measurements of the system that have been taken since power was applied to the circuitry of the computing device. These measurements are indicative of the software that is executed during the boot process and of the presence and configuration of various hardware components. If the proper measurements were made in the correct order, then the PCRs of the TPM would contain values that could be used to verify that the computing device did indeed boot in a recognizable way. If the measurements are recognized to represent a computer that has booted in a trusted way, then the machine is in a trusted state when it begins executing the operating system software. In such a manner, malicious code in the boot sequence can be detected.
The measurements that are made during the boot process, and the resulting values stored in the PCRs of the TPM, can define the trust state of the machine. As such, those PCR values can be utilized as part of the “attestation” and “sealing” mechanisms that can be performed by the TPM. “Attestation” generally refers to the provision of signed versions of one or more PCR values to an external entity so as to prove that the computing device is in a trusted state. Specifically, one or more PCR values are signed by the TPM using its private key and then transmitted to an external entity. The external entity can verify that the PCR values did indeed come from the indicated computing device, based on the fact that the PCR values were signed with the TPM's private key, and can further verify, based on the values of the PCRs themselves, that the computing device was placed into a trusted state. “Sealing”, on the other hand, refers to the retention of a secret, by the TPM, which should only be released by the TPM if the values of relevant PCRs are the same as they were when the secret was provided to the TPM to be “sealed.”
Unfortunately, the measurements made during the boot process, and the resulting values stored in the PCRs of the TPM, can be dependent on factors that may not impact the security of the computing device. For example, the order in which some components are executed may be irrelevant and, consequently, there may not exist a precise control mechanism by which their execution order is controlled. If the order in which such components are executed changes, the values of one or more PCRs, as maintained by the TPM, may likewise change. As a result, secrets that were sealed by the TPM based on a particular set of PCR values will now no longer be unsealed, even though the state of the computing device has not materially changed. Similarly, attestation to an external entity may also fail, since the PCR values attested to by the TPM differ from those believed, by the external entity, to be indicative of a trusted state of the computing device.
As described above, the mechanisms of attestation and sealing are “fragile” because they can easily cause secrets to remain sealed, or computing devices to be found not in a trusted state, when their software load would have satisfied the given policy, if it were capable of being expressed generally enough. To provide more rigorous attestation and sealing mechanisms, the concepts of “generalized attestation” and “generalized sealing” have been developed. Unlike the sealing described above, generalized sealing does not seal a secret to a precise and immutable set of PCR values, but rather seals the secret to one or more policies that can be verified through a range of PCR values. Similarly, unlike the attestation described above, generalized attestation enables the trusted state of a computing device to be verified by reference to one or more policies that can be expressed via a range of PCR values.
In the generalized attestation and generalized sealing mechanisms, lists or sets of measurements are referenced, rather than individual PCR values. More specifically, in addition to, or as an alternative to, maintaining the PCR values in the manner described above, the TPM can also maintain one or more lists, or logs, of values uniquely identifying each component of the computing device that was utilized or executed during the boot process. Typically such uniquely identifying values will be hash values obtained by hashing some or all of the component utilized or executed.
During the generalized attestation and generalized sealing mechanisms, these logs of hashes are simplified and then referenced according to one or more policies. In particular, larger systems, such as an operating system, or a set of graphics drivers can comprise multiple components. When referencing the log of hashes of components utilized or executed during the boot process, the hash value of a component known to be part of a larger system, such as an operating system, or a set of graphics drivers, can be replaced by an identifier of the larger system, such as the name of the operating system or the set of graphics drivers. Ultimately, the log of hashes of components utilized or executed during the boot process can be pared down to a list comprising multiple entries identifying larger systems, such as an operating system or a set of graphics drivers and some, or possibly even no, unidentified or uncategorized hashes. Generalized attestation and generalized sealing can then be performed based on whether the few, or no, remaining hashes, and the listed larger systems, are trusted. Because individual components of larger systems are ultimately pared down to merely an indication of the larger system, the precise order of execution of each of those components during the boot process need not influence the determination of whether the computing device is in a trusted state.
Generalized attestation and sealing can be performed, not only within the context of a single computing device, but also through communications between multiple devices. For example, remote attestation can be utilized as part of a Network Access Protection (NAP) scheme. Specifically, one computing device, seeking to join a network protected by another computing device, can provide the log of hashes of the components that have been installed or executed on that computing device to the computing device protecting the network. To enable verification of the log, one or more PCR values can also be provided in a secure manner, such as by being signed by the TPM of the computing device seeking to join the network. The computing device protecting the network can then utilize the generalized attestation mechanisms described above to collapse the log of hashes into identifications of larger components and can perform an evaluation of the computing device seeking to join the network based on these larger components, and any other hashes remaining in the log. The computing device seeking to join the network has, thereby, remotely attested to its current state. A remote sealing can be similarly accomplished, with a second computing device evaluating the provided log and signed PCR values, not for a determination of, for example, whether to let the other computing device join a network, but rather in order to determine whether to unseal information and provide it. Some existing Rights Management Services (RMS), for example, utilize such a remote sealing operation.
Unfortunately, TPMs represent a hardware cost to the manufacturer of the computing device that the manufacturer cannot easily recoup. Consequently, manufacturers have selected very inexpensive TPMs that comprise very little computational ability, as compared to modern processors and other processing components of a computing device. Thus, while modern TPMs comprise sufficient computational capability to sign PCR values in order to provide them to other computing devices, and thereby perform remote attestation and remote sealing, they generally do not comprise sufficient computational capability to sign any other messages that may be exchanged coincident with the remote attestation or remote sealing. Because remote attestation and remote sealing can be utilized in a variety of mechanisms, and each such mechanism can comprise a relevant protocol, TPMs with substantially more computational abilities than modern TPMs would be required to accommodate signing messages and supporting such a myriad of protocols. TPMs with such computational abilities represent costs that are not likely to be voluntarily accepted by computing device manufacturers.